The following information provides a basic understanding of the SNMP protocol and related concepts. This topic does not demonstrate usage of PowerSNMP for ActiveX; for usage information, see Code Examples or Assembly Documentation.
SNMP provides basic network monitoring and management functions between management stations ("managers") and managed nodes ("agents"). Managers get and set agent data using a query-response protocol over UDP. Agents also send unsolicited informational messages ("traps" and "notifications") to managers. SNMP version 2 enhanced and added features to version 1. The most current version of SNMP is version 3, which added security to version 2.
Agents listen for queries on the well-known port 161. Managers listen for traps and notifications on the well-known port 162. Managers can use any port for sending requests; agents will respond to the message's source address and port.
The SNMP MIB (Management Information Base) contains objects to be managed. Objects in the MIB are assigned OIDs (Object Identifiers). A typical OID is 1.3.6.1.2.1.1.1 (sysDescr). An SNMP variable is an instance of a MIB object, and contains a value. SNMP messages generally include one or more variables. The following chart describes the various SNMP message types.
| Message Type | Version | Description |
|---|---|---|
| Get Request | 1, 2, 3 | A manager requests the values of one or more variables supported by an agent. |
| GetNext Request | 1, 2, 3 | A manager requests the values of the next lexicographical variables supported by an agent. |
| GetBulk Request | 2, 3 | Similar to a GetNext, but multiple "next" values can be requested for each variable. |
| Set Request | 1, 2, 3 | A manager sets the values of one or more variables supported by an agent. |
| Response | 1, 2, 3 | An agent confirms receipt of a manager's Get, GetNext, GetBulk or Set request, or a manager confirms receipt of an Inform request. |
| Inform Request | 2, 3 | A manager or agent sends information to a manager. |
| Trap | 1 | An agent informs a manager of an event. |
| Notification | 2, 3 | An agent informs a manager of an event (replaces Trap messages in version 2 and 3). |
| Report | 2, 3 | Used in version 3 to send security information. |
Object and instance identifiers are defined using the Abstract Syntax Notation One (ASN.1) standard.
An object identifier (OID) uniquely describes a node within the Management Information Base (MIB) tree. Each node in the tree is a definition; not an actual instance of an object. Typical OIDs include "1.3.6.1.2.1.1" and "1.3.6.1.2.1.1.1," which correspond to the "system" branch and "sysDescr" object, respectively.
A MIB tree leaf node may be referenced as an object instance, with an instance identifier (IID). There are two possible type of leaf nodes:
A Management Information Base, or MIB, is a definition of managed objects in a text file. Such files are commonly called "MIB files," and are shared between SNMP agents and managers to define a language of objects. PowerSNMP has built-in support for many standard MIB definitions, and supports importing additional definitions. To import MIB files, use Mib.Import() at runtime.
When loading one or more MIBs, you may receive an exception such as:
An error occurred while compiling example1.mib (line #1000) - "example1-Products" could not be resolved. The MIB file defining this identifier should be included as a parameter to the Import() method.
This indicates that the MIB(s) contain a MIB dependency that has not been loaded. Open the MIB(s) in a text editor, and examine the IMPORTS clause to find the referenced definition or module. For example, an IMPORTS that contains:
example1-Products
FROM EXAMPLE1-MIB
Means that you must load the MIB named "EXAMPLE1-MIB" before or at the same time as the MIB containing this IMPORTS.
Note that some MIBs may contain definitions referencing objects, syntaxes, etc, defined within a dependency's dependency (etc), so you may need to examine the MIB(s) referenced in a MIB's IMPORTS clause to determine the MIB(s) required by a MIB's definitions.